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RESPONSE TO EXAMINER'S ANSWER 



Appellant Rebuttal to the "(10) Response to Argument" section on pages 12-24 of the 
Examiner's Answer dated June 24, 2010 

General Comment 

Generally speaking, and as will be further shown below, the cited reference to Derby is 
directed to translating addresses, and locates hardware devices - and not services. The cited 
Elnozahy passages describe updating a directory - and subsequently replication of such directory 
update to other replica servers - in response to a request to 'advertise' services in a given 
namespace. 

Paragraph I on Page 12 comments 

Claim 3 is in fact directed to a method of balancing demand for network services. For 

example, such claim recites: 

"A method of balancing demand for networked services in a distributed data 
processing system, the method comprising the steps of: 

initializing one or more local service managers within the distributed data 
processing system, wherein each local service manager has information about and 
provides access to networked services defined within a respective local region of 
the distributed data processing system for clients within the distributed data 
processing system, and wherein each client is uniquely associated with a local 
service manager; 

initializing one or more distributed service managers within the 
distributed data processing system, wherein each distributed service manager 
provides access to the networked services to the local service managers within 
the distributed data processing system, and wherein each local service manager is 
uniquely associated with a distributed service manager; 

receiving, at a distributed service manager, a request for a networked 
service from a local service manager for which the local service manager lacks 
information; 

determining whether the distributed service manager has information 
about a networked service with one or more characteristics that match one or 
more parameters in the request for a networked service, wherein the determining 
step is accomplished by reference to a cache maintained by the distributed service 
manager which contains information resulting from prior requests for networked 
services; and 
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returning information for referencing a matched networked service." 

This 'balancing' is achieved by the determining and subsequent returning steps with 
respect to the request for a networked service and prior requests for network services in that a 
'local' cached version is used upon an occurrence of a 'match' - thereby avoiding a need to 
obtain such service from a 'distributed' source, and thus resulting in load balancing of the 
request. 

Paragraph II on Page 12 comments 

The Examiner asserts that since the LAN access agent knows which services are located 
on the local configuration, it teaches a "unique association with a local service manager". 
Appellants urge that such assertion fails to address or take into account the 'client' aspect of 
Claim 1, where each 'client' is uniquely associated with a local service manager. The 
Examiner's assertions are with respect to a local service manager and the services it provides - 
and is not directed to characteristics of 'each client', as claimed. 

It is further noted that the Derby LAN access agent - which the Examiner alleges is 
equivalent to the claimed 'local service manager' - is not described as providing access to 
networked services defined within a respective local region, as claimed. Instead, the LAN 
access agent 'mediates' between a LAN and WAN to provide 'hardware' interconnect (Derby 
col. 5, lines 56-58; col. 6, lines 50-59), and is not geared toward knowledge of any 'services' that 
may be provided by such underlying hardware. To the extent that Derby describes a directory 
services 22, this block provides an address translation from a LAN-based address to a 
corresponding WAN-based address to provide 'station' - and not 'service' - reachability (Derby 
col. 6, lines 18-32). This can also be seen by the fact that Derby merely translates addresses of 
stations , and does not analyze or manipulate other aspects of the payload, such as determining 
what service may be requested in the underlying packets it receives. 

Paragraph in on Page 14 comments 

The cited passage at Derby col. 7, lines 17-48 describes internal operations of the 'LAN 
access agent' - which the Examiner asserts is equivalent to the claimed 'local services manager'. 
In contrast, this aspect of Claim 3 ("receiving a request for a network service") is directed to an 
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action performed by another claimed element ('distributed service manager') that is different 
from the 'local services manager' ("receiving, at a distributed service manager, a request for a 
networked service"). Thus, this description of operations/actions performed by the alleged 'local 
services manager' does not teach operations/actions performed by the claimed 'distributed 
service manager' - which is a separately claimed element. 

It is further noted that the Derby 'results' of any alleged 'request' is the location of a 
'station' and not a 'service' (Derby col. 7, lines 37-40), as further described in the Appeal Brief. 

Paragraph IV on Page 14 comments 

The cited passage describes locating a 'station' and not a 'service'. In addition, to the 
extent this cited passage describes a 'cache', this cache contains 'network layer addresses', 
including MAC addresses and WAN transport addresses (col. 7, lines 37-45), and does not 
contain information resulting from prior requests for network services - further evidencing that 
this cited passage describes locating a 'station' and not a 'service'. 

Paragraph V on Page 15 comments 

Per Claim 3, "wherein each distributed service manager provides access to the 
networked services to the local service managers within the distributed data processing system". 

The CDS server (alleged as being equivalent to the claimed 'distributed service manager') 
would never provide access to a networked service to the redundant replica server (alleged as 
being equivalent to the claimed 'local service manager') since the redundant replica service is a 
backup of the CDS server and therefore the CDS server would have no need or reason to provide 
network services access to such redundant replica server. 

Paragraph VI on Page 17 comments 

See Paragraph V discussion above. 

Paragraph VII on Page 18 comments 

The Examiner states that a request is forwarded to (i) master CDS server, and (ii) each 
available replica agent, and that "If the request is forwarded, it is received". Appellants urge that 
such assertion fails to account for the 'for which the local service manager lacks information' 
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aspect of Claim 3. The Elnozahy 'replica server' is alleged as being equivalent to the claimed 
'local service manager' , and yet the cited reference does not describe that its replica server lacks 
information that results in the master CDS server (which is alleged as being equivalent to the 
claimed 'distributed service manager') receiving a request for a network service from such 
replica server. 

Paragraph VIII on Page 18 comments 

The cited passage does not describe returning information for referencing a matching 
network service . Instead, the 'reply' that is returned is the reply from an 'update' request that 
requests to advertise its services in a namespace (Elnozahy col. 2, lines 35-39; col. 6, lines 22-25 
and 29-34). This is a fundamental and key distinction. 

Paragraph IX on Page 19 comments 

For similar reasons to those described above with respect to Paragraph VIII, the cited 
passage at Elnozahy (specifically, col. 6, lines 21-34) describes updating a directory in response 
to an 'update' request, and thus does not describe any type of characteristics pertaining to a 
matching network service , as claimed. 

Paragraph X on Page 20 comments 

In rejecting Claim 38, the Examiner alleges that 'Chandra' teaches all aspects of such 
claim (see page 7 of the Final Office Action dated June 2, 2009, where Chandra col. 6, lines 10- 
34 are cited as teaching various aspects of Claim 38), and yet in the Examiner rebuttal section of 
the Examiner' s Answer - and in particular this Paragraph X response on page 20 of such 
Examiner's Answer - the Examiner now alleges that 'Elnozahy' teaches the claimed returning 
step. Such inconsistency strongly evidences that Claim 38 was erroneously rejected in the final 
rejection of such claim due to the Examiner's attempt to 'rehabilitate' the final rejection of such 
claim in the Examiner's Answer using different reasons from those used in the final rejection. 

It is further noted that Elnozahy describes updating a directory in response to an 
advertising request, as previously shown, and does not describe returning information pertaining 
to a matched network service, as claimed. 
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Paragraph XI on Page 21 comments 

The cited passage at Elnozahy col. 1, lines 41-59 does not describe any type of service 
'matching' operation being performed, and therefore does not describe "wherein one of the 
characteristics of a matching service is a type of service" as per Claim 39. For example, this 
cited passage does not describe a 'type' of service, or that a characteristic of a matching service is 
a 'type' of service. 

Paragraph XII on Page 21 comments 

The Examiner asserts that (i) the 'response time' for a request and (ii) a server's 
proximity or hop distance are network related metrics. However, neither of these alleged metrics 
are described as being a part of any 'comparing' step, as is provided by the features of Claim 11. 

Paragraph XIII on Page 22 comments 

The cited passage describes that information is analyzed and a server is selected based on 
a policy. Such server selection does not describe characteristics of a 'distributed service 
manager' or a 'localization module' included in a 'distributed service manager'. This cited 
passage also does not describe that parameters within respective localization modules are tailored 
to provide different load balancing for corresponding 'distributed service managers' themselves . 

Paragraph XIV on Page 22 comments 

Claim 37 is directed to particular characteristics pertaining to the 'configuration' of the 
'local services manager' and how it interacts with an object request broker. The 'local services 
manager' is specially configured for three different scenarios: (i) services that provide internal 
service and which are valid only in a scope of a local ORB (with the 'local services manager' 
being configured to not provide access to such services); (ii) services that are instantiated on each 
ORB only through requests based on an ORB identifier (with the 'local services manager' being 
configured to provide access to such services); and (iii) services that may be accessed from 
outside the scope of the local ORB through requests based on both a service specification string 
AND an ORB identifier (with the 'local services manager' being configured to provide access to 
such services). 

The Examiner cites Fowler's description at col. 7, lines 39-58 as teaching the 'local ORB' 
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scope and not providing access to ORB services (item (i) above). Appellants urge that this cited 
passage does not describe any type of 'local service manager' that is specially configured to not 
provide access to object request broker (ORB) services (i) that provide internal service and (ii) 
which are valid only in a scope of a local ORB", as claimed. Thus, contrary to the Examiner's 
assertion, Fowler does not teach/suggest all aspects of Claim 37. 

It is further noted that Fowler does not describe any configuration of a 'local services 
manager', and therefore also does not describe/suggest items (ii) and (iii) listed above. 
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CONCLUSION 



The cited reference to Derby is directed to translating addresses, and locates hardware 
devices - and not services. The cited Elnozahy passages describe updating a directory - and 
subsequently replication of such directory update to other replica servers - in response to a 
request to 'advertise' services in a given namespace. 

As shown above and in the Appeal Brief, the Examiner has failed to state valid rejections 
against any of the claims. Therefore, Appellants request that the Board of Patent Appeals and 
Interferences reverse the rejections of such claims. 



Date: August 20, 2010 Respectfully submitted, 
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